REMARKS 



Applicant is in receipt of the Office Action mailed August 10, 2006. New claim 
21 has been added. Thus, claims 1-21 are pending in the case. Reconsideration of the 
present case is earnestly requested in light of the following remarks. 

Section 101 Rejections 

Claims 1-20 were rejected under 35 U.S.C. 101 for not producing "a real life, real 
world, useful, concrete, and tangible result". Applicant respectfully disagrees. Applicant 
understands that an invention must be operable to produce a "useful, concrete, and 
tangible result", and respectfully submits that the claims as currently written meet these 
criteria. 

Claim 1 recites: 

1. A memory medium that stores program instructions implementing an 
application programming interface (API) for synchronizing multiple devices in a system, 
wherein the API comprises: 

a plurality of functions invocable in a program to synchronize a plurality of 
devices, wherein each function is executable to perform a respective functionality related 
to synchronizing the plurality of devices, and wherein at least one of the plurality of 
functions is executable to access a plurality of instrument drivers corresponding 
respectively to the plurality of devices to synchronize the plurality of devices; 

wherein, in synchronizing the plurality of devices, the plurality of functions are 
executable to: 

determine a trigger clock signal for each of the plurality of devices; and 
synchronize the plurality of devices based on the determined trigger clock 

signals. 

Applicant respectfully submits that synchronizing a plurality of devices in a 
system has clear practical use and effect, such as, for example, in industrial systems 
directed to measurement, automation, and control, among others. As the Examiner is 
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certainly aware, device synchronization is often not only beneficial in such systems, but 
is often necessary for successful operation of the systems. The present invention, being 
directed to improved means for performing such multi-device synchronization, 
specifically, an application programming interface (API) for performing such 
synchronization, is thus useful, and is clearly operable to produce a "useful, concrete, and 
tangible result", specifically, the synchronization of a plurality of devices in a system. 

Moreover, Applicant has added a new independent method claim that particularly 
recites the performance of such multi-device synchronization via the API. 

Applicant thus respectfully submits that the section 101 rejection of claims 1-20 is 
improper, and respectfully requests its removal. 

Section 102 Rejections 

Claim 1 was rejected under 35 U.S.C. 102(e) as being anticipated by Conway et 
al. (USPUB 2004/0064750, "Conway"). Applicant respectfully disagrees. 

As the Examiner is certainly aware, anticipation requires the presence in a single 
prior art reference disclosure of each and every element of the claimed invention, 
arranged as in the claim. Lindemann Maschinenfabrik GmbH v. American Hoist & 
Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 1984). The identical invention must be 
shown in as complete detail as is contained in the claims. Richardson v. Suzuki Motor 
Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

In asserting that Conway discloses the claimed application programming interface 

(API), the Office Action cites paragraphs [0007] - [0008] of Conway, which read thusly: 

[0007] The instrumentation hardware may be configured and controlled by 
software executing on the computer system. The software for configuring 
and controlling the instrumentation system typically includes driver 
software and the instrumentation application software, or the application. 
The driver software serves to interface the instrumentation hardware to the 
application and is typically supplied by the manufacturer of the 
instrumentation hardware or by a third party software vendor. The 
application is typically developed by the user of the instrumentation 
system and is tailored to the particular function that the user intends the 
instrumentation system to perform. The instrumentation hardware 
manufacturer or third party software vendor sometimes supplies 
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application software for applications that are common, generic, or 
straightforward. 

[0008] Instrumentation driver software provides a high-level interface to 
the operations of the instrumentation device. The instrumentation driver 
software may operate to configure the instrumentation device for 
communication with the host system and to initialize hardware and 
software to a known state. The instrumentation driver software may also 
maintain a soft copy of the state of the instrument and initiated operations. 
Further, the instrumentation driver software communicates over the bus to 
move the device from state to state and to respond to device requests. 

As the above paragraphs make clear, in prior art approaches to device 
synchronization, application programs, e.g., written by the user, make calls to respective 
instrumentation drivers to interact with the respective devices, e.g., to coordinate 
synchronization among devices. Note that the application program must make individual 
calls to each respective instrument driver to interact with the respective device, and so to 
synchronize multiple devices, the application must make corresponding multiple (direct) 
calls to the respective instrument drivers of the devices. Thus, there are two software 
layers involved in synchronization of the devices — the application layer, and the driver 
layer. 

In direct contrast, one embodiment of the present application describes an API 
(comprising a plurality of functions) as an intermediate software layer interposed 
between the application layer and the driver layer, where, as claimed, the program 
(application) makes calls to the functions of the API, and these functions access the 
drivers. Moreover, as recited in the claim, at least one of the functions "is executable to 
access a plurality of instrument drivers corresponding respectively to the plurality of 
devices to synchronize the plurality of devices". In other words, rather than having to 
access each instrument driver individually via a respective function call as per the prior 
art, all of the instrument drivers of the plurality of devices are accessible via a single 
function call (the at least one of the functions) to synchronize the devices. Thus, the 
addition of this intervening layer (i.e., the present API) significantly simplifies 
synchronization of multiple devices. 

Nowhere does Conway, in the cited paragraphs or elsewhere, teach or suggest 
such an API, nor, more specifically, such an API function that is executable to access 
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multiple instrument drivers to synchronize the plurality of devices. In fact, Conway fails 
to even mention an API at all. 

Thus, for at least the reasons provided above, Applicant submits that Conway fails 
to teach or suggest all the features and limitations of claim 1 , and so claim 1 and those 
claims dependent therefrom are patentably distinct and non-obvious over Conway, and 
are thus allowable. 

Removal of the section 102 rejection of claim 1 is respectfully requested. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. 

If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the 
above referenced application(s) from becoming abandoned, Applicant(s) hereby petition 
for such extensions. If any fees are due, the Commissioner is authorized to charge said 
fees to Meyertons, Hood, Kivlin, Kowert & Goetzel PC Deposit Account No. 50- 
1505/5 150-82100/JCH. 



Respectfully submitted, 

/Jeffrey C. Hood/ 

Jeffrey C. Hood, Reg. #35198 
ATTORNEY FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, Kowert & Goetzel PC 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: November 9, 2006 JCH/MSW 
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